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Abstract 

Data Communications has always played an important role in the operation of the utility 
system from high-speed relay communications to the recent expansion in “inter-control 
center’ data sharing. The increasing incorporation of digital devices throughout the 
utility enterprise as well as the forces of deregulation are driving utility communications 
into new realms with new requirements and paradigms. This paper examines the 
communication issues in the Independent System Operator (ISO) environment including 
inter ISO communication of status data, accounting issues, and power system control. 


Solutions to these issues from a system protection / Intelligent Electronic Device 
perspective are examined. In particular, this paper examines the next generation 
protection communications that will be available shortly and its effect on next generation 
SCADA. Communication in the realm of power system control will also be examined 
and the communication infrastructure required to achieve such is discussed. 


Deregulated Utility Communication Requirements 
The trend toward electric utility deregulation is moving full speed ahead throughout the 
world. As a result, the integration, consolidation, and dissemination of information both 
inter and intra utilities has become a critical piece of the deregulation picture. Information 
traditionally used only within a given utility now becomes desired by many players. The 
general trend in the industry has been toward the use of the Internet for the transfer of 
data such as: 

e Available Transmission Capacity 
Rate Schedules 
Scheduling (especially inter-company) 
e Operating Constraints 
e Interruption Criteria 


Beyond data sharing, new mandates are being places on the transmission and distribution 
utilities to minimize outage times, provide rate alternatives (for example, through 
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Demand Side Management), maintain operating data archives, and in general, push more 
power through existing power lines. 


On the financial side, deregulation introduces the need for the sharing of accounting data 
among utilities, ISOs, metering firms, billing firms, and Independent Power Producers. 
Inter-utility billing must be correct and standardized. Standard accounting and record 
keeping topics to track include: 


Revenues 
Costs 
Liabilities 
Assets 


Another fall-out of deregulation is the merger and consolidation of many of the existing 
utilities. Mergers will require the establishment of intra-company communication and the 
integration of data from companies control centers, power plants, and substations. 
Implementing this integration with different data models and communication protocols 
will add considerable time and money to the process. The possibility, nae, inevitability of 
the need to perform this integration process should drive all utilities toward the 
standardization of data models and communication protocols. 


The Solution 

The issues listed above are not new nor has the industry been standing still in searching 
for a solution. In particular, the Electric Power Research Institute (EPRI) launched a 
concept in 1990 known as the Utility Communication Architecture or UCA. The goal 
behind UCA was to identify a suite of existing communication protocols that could be 
easily mixed and matched, provide the foundation for the functionality required to solve 
the utility enterprise communication issues, and be extensible for the future. UCA 
provides a “network” solution to the interconnection of data sources — similar to the web 
solution used throughout the world to interconnect computers. 


At this time, the next generation of Intelligent Electronic Devices (IEDs) based on UCA 
are coming to the market. These devices are focused on networking in the substation and 
are based on an MMsS/Ethernet profile (MMS defined later) with one of two 
“networking” layers in-between (see figure 1). 


Manufacturing Messaging Specification 
(MMS) Application Layer 


International Standards TCP/IP 
Organization - OSI Networking Stack Network Layer 
Networking Stack 


10Mb Ethernet 
10BaseT and 10BaseFL Media Data Link and 
(Twisted pair and Fiber) Physical Layer 





Figure 1 
Substation Network Profile 
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Network Solution Features 


Physical / Data Link layer 

Ethernet was chosen as the Physical / Data Link layer due to its predominance in the 
marketplace and the subsequent availability of low-cost implementations and associated 
network hardware (such as bridges and routers). In addition, the scalability of Ethernet is 
well defined with 100Mb implementations being fairly common and 1Gb Ethernet well 
on its way into vogue. Processors are available today with multiple 10 Mb Ethernet ports 
integrated into the chip and next generation designs are planned with 100 Mb ports. 


A concern was raised early on as to the reliability of the “on time” message delivery 
capability of Ethernet due to the Carrier Sense Multiple Access (CSMA) nature of 
Ethernet. When two or more IEDs desire access to the Local Area Network (LAN) 
simultaneously, a data collision may occur. When this happens, all colliding devices set a 
random delay time and try again after the delay to get access to the bus. There is a 
probability that subsequent collisions may occur which would delay critical messages 
from being delivered in a timely manner. For the substation environment, “timely” was 
defined to be 4ms in order to perform functions such as tripping over the LAN. 


To quantitatively address this concern, a study was undertaken by EPRI where the 
performance of Ethernet was evaluated under a “worst case” scenario in comparison to a 
12 Mb Token Passing Profibus network. Results of this study [1] showed that either 
100Mb Ethernet on a shared hub or 10Mb Ethernet connected via a switched hub could 
meet the 4ms network communication time - both of which were faster than the token bus 
solution operating at 12Mb. 


Network Layer 

As it was deemed desirable to be able access data from any device from anywhere in the 
corporate enterprise, a complete Network communication layer (the software that handles 
getting data from here to there) was included in the profile. Two solutions were adopted 
for the Network layer - TCP/IP and the International Standards Organization -Open 
System Interconnect. 


TCP/IP stands for Transport Control Protocol / Internet Protocol which is the ubiquitous 
network layer used over the Internet. Clearly, its inclusion in the profile is due to its 
omnipresence and overall acceptance in the marketplace. TCP/IP is a streaming protocol 
which means that transmission of a packet of data waits for a “stream” of data (such as 
that from a teletype terminal) to fill a buffer before the buffer is transmitted. This mode 
of operation could potentially slow down the communication of small packets of data. It 
should be noted, however, that there are controls available on the size and delays times of 
sending a packet of data. In addition to the streaming aspect, TCP/IP has built in 
congestion control that will drop packets of data if the network is deemed too busy. This 
feature is not desirable in the delivery of real time data. 
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The other Network layer included is the ISO-OSI network layers. ISO is the International 
Standards Organization which has established the Open System Interconnect (OSI) seven 
layer model. This model is implemented through a number of standard protocols in the 
Network layer and does not suffer from the need to wait until a buffer is full before 
transmitting. Both network layers support the concept of “broadcasting” a message for all 
devices on the bus to hear. This feature is very desirable for functions such as data 
capture triggering, time synchronization, and even control messages to multiple devices. 


Application Layer 

On top of all these layers, we come to the heart of this standard profile - the Application 
Layer. The application layer is a set of services for moving and operating on data. The 
application layer can be compared to the system functions that are a part of FORTRAN. 
In FORTRAN, there are “system calls” to perform such function as “Open File”, “Read 
File”, “Write File”, etc that operate between the user program and the operating system. 
The application layer performs just these kinds of services but operating between devices 
over a network. As such, one can speak of reading or writing data and other services 
among devices not only on the local network but also through the Wide Area Network 
(WAN). 


The application layer chosen for the utility profile is the Manufacturing Messaging 
Specification (MMS). MMS provides a rich set of some 87 services for this function, 
however, it was determined that only a small subset of these services were necessary to 
meet the functional requirements spelled out by the industry [2]. The required services 
have been defined in the Common Application Service Module (CASM) document{[3]. 


There are a number of key services that facilitate the operation and integration of a 
network relay in an enterprise as well as lend themselves to providing data to multiple 
requesters in the ISO environment, namely: 


Get Object Definition: This service, when issued by any host / client computer, 
download a definition of every variable known to the IED. This service can be 
equated to meeting a stranger and asking the question “who are you?”. 
Implementation of this service provides automatic creation / update of the host 
database for that relay. As the software in an IED is often upgraded in the field, 
this feature automatically keeps the Host database up to date. Note that the ISO 
Network protocol will automatically detect a new device on the network. As 
such, the Host computer can automatically create and maintain a list of all the data 
objects available in the substation. Note that this function is also available 
remotely over the network. 


Named Variable Lists: Today’s IED contain hundreds of present value 
measurements. The manufacturer typically provides a pre-configured “present 
value” command that fetches a factory defined set of data. In general, however, 
utilities typically have their own definition of what they would like to see in a 
present value message. MMS provides a service that allows the user to define a 
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particular set of data to be retrieved and assigns a name to that data set. For 
example, the billing agent for a client would need to collect the kilowatt-hour 
usage for a particular line or set of lines. A “name list” could be established that 
retrieved only that data on request. Furthermore, the IED could be set-up with 
security access such that the billing data could appropriately restricted. Typical 
“name lists” would include: SCADA Data, Power Quality, Outage Report, 
Demand Data, and Equipment Health. 


Unsolicited Event Notification: Event collection in a substation today is 
performed on a polled basis, that is, some master controller sends a request for 
data and a list of events are then transmitted as requested. MMS supports 
“unsolicited” event collection, that is, the event is automatically transmitted upon 
change of state. This concept is extended to the transmittal of other data in the 
substation where data transmission can be initiated by the change of an analog 
value outside of some bound or change of state of a status indication. 


File Transfer: Upon request, MMS will transfer files from a “server” to the 
requesting client. Large blocks of data are automatically segmented, transferred 
block by block, re-assembled in the client machine, and write the file onto an 
organized storage media. This function can be used to transfer both file data such 
as demand data, oscillography, and events as well as program files. 


Use of Object Models 

Having put in place a system to manipulate data, the question arises as to what data and 
how is it to be organized. This part of the communication model is often called the “User 
Layer”. The answer to this question can be found in the concept of object modeling. An 
object model is a representation of a physical object or abstract concept. For example, a 
relay makes measurements of voltage, current, and power on a monitored transmission 
line. The measurements made by the relay can be organized in a “measurement model” 
containing all the elements mentioned above. If additional measurements such as power 
quality and power factor are added at a later date, the original model is easily expanded to 
accommodate this data. 


Why use object models? First of all, modeling of the data creates an independent 
representation of the data that is not linked to a physical location or storage method inside 
the relay. Representation of the data in models make is easy to visualize what happens to 
data in its local environment as well as its interaction with other elements of the modeled 
device. Physical representation has now been standardized under a Unified Modeling 
Language (UML). As such, object models can easily be shared with others. 


Primary in this implementation, however, is that modeling provides a way to standardize 
information exchange between other models / devices. Such an object standardization 
has been created under UCA which is known as the General Object Model for Substation 
and Field Equipment (GOMSFE) [4]. GOMSFE contains models for metering, 
protection elements, control, security, and a host of other items. The models were based 
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on what was perceived to be the “most” common elements found in an IED. Once 
standardized, users can issue requests to the IED for “standard” object values. For 
example, a utility SCADA system can automatically request Volts, Amps, Watts, Vars, 
and Status from an IED without having any knowledge of the manufacturer or of the IED. 
Do note that it is almost impossible to standard on all possible object in an IED as there 
are many “vendor specific” objects that serve as differentiators between vendors. 


Common Accounting Model 

As mentioned in the introduction, the deregulated utility environment will usher in a new 
wave of electronic brokering as electricity is bought and sold in a commodities market. 
Tracking of these transactions within a given utility should be manageable, however, 
most of these transactions will span multiple companies. In order to achieve 
interoperability in this environment, implementation of an accounting object model 
similar to that in the electric plant is recommended. This type of model is also known as 
a three schema architecture [5]. The three schema architecture has been recognized as the 
architecture of choice in the Information Technology (IT) community for many years. 
Conceptually, it has much in common with the concept of hubs that airlines use to 
profitably carry people between numerous pairs of cities. 


There are three layers in a three schema architecture. The top layer is the external 
interface, and is the layer that users view the system (the common object models). The 
middle layer is the service layer that performs computations and other data services 
(MMS). The bottom layer is the actual data model. Like the hub in an airline system, the 
data model provides a central focal point for all services to obtain data. Also, the use of a 
common data model promotes standardization. We are recommending the development 
of a common accounting model to be shared by utilities. 


The techniques for building an object model in a three schema architecture are well 
known[6]. Major components of the mode includes object classes (such as accounts and 
persons) relationships, (such as person has an account), and inheritance, (such as a 
rectangle is a polygon). 


Architectural Implementation 

Given IED’s that implement the communication profile described above, one can now 
assemble a system that makes use of the functionality previously defined. Figure 2 
illustrates a network architecture of such a system. In this implementation, operation of 
the IEDs, the Network, and the Host computers / Operator Interfaces is totally separated. 
In other words, failure of the host computers would have no effect on the inherent 
operation of the system. All IEDs on the network respond to requests from any other IED 
on the network. “Next Generation” SCADA is effected as a Bridge or Router interface 
onto the utility WAN. All data available in the connected IEDs (including the object 
definitions) become available to any networked device. User defined information, 
through the implementation of user defined Name Lists, can now be selectively delivered. 
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Figure 2 
Next Generation Substation Network Architecture 


It is understood that the transition from present SCADA to next generation SCADA will 
not take place overnight. Nevertheless, the illustrated architecture accommodates legacy 
SCADA interface through the use of SCADA Gateways. These gateways act as protocol 
translators from the MMS objects available on the LAN to the traditional SCADA data 
required by the remote SCADA Master. Additionally, it is recognized that many 
substations will contain “legacy” IEDs whose data would be desired in an integrated 
environment. As such, a similar gateway function can effected by the Host computer or 
any other independent computer. Ultimately, data retrieved from the legacy IEDs can be 
made MMS accessible. 


The peer to peer communication environment opens up new vistas for protection 
applications in the electrical plant. Traditional protection schemes used hard wires and 
wired logic to implement the various protection schemes. Peer to Peer communications 
now allows for information transfer through the use of Virtual Outputs (VOs) and Virtual 
Inputs (VIs). Any device can define a VI that is linked to an object in another IED (either 
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local or literally anywhere on the network). Linkage would be specified by IED address, 
object name, object type, and security. The requesting device gets access to the desired 
object either on request, on change of state (or deadband), or periodically. Since plant 
control requires a high degree of reliability, provision is made to implement redundant 
communications from the IEDs and subsequently, support for a redundant LAN. 


Power System Control 

Looking into the near future, many “next generation” IEDs will be able to synchronize 
their data capture and measurements to the Global Positioning Satellite (GPS) system. 
Such synchronization will allow measurements that give an instantaneous snapshot of the 
state of the power system. Given the “observability” of the state of the power system, 
optimal control theory indicates that there is a good chance of being able to “control” the 
power system. For example, if one were able to detect a potentially unstable power swing 
in progress on the power grid, control actions could be taken in tenths of a second to 
bring the power system back to a stable state. The network architecture described above 
(both LAN / WAN) now provides the foundation to effect the high speed measurements 
and subsequent control actions required to implement this next generation functionality. 


Conclusions 

Deregulation will place new requirements on the communication of data and information 
throughout the utility enterprise. Utilities need to find standardized methods of 
communicating the various pieces of the data puzzle among themselves. The Utility 
Communication Architecture (UCA), in conjunction with advanced function IEDs, 
provides a path toward such standardization which will become the foundation of the next 
generation of utility protection, control, and monitoring. 
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